REMARKS 



Claims 1-8 and 10-19 are currently active. 

Claim 9 has been canceled. Antecedent support for the amendments to the 
claims is found on page 10, lines 3 and 4. 

The Examiner has rejected Claims 8-19 as being directed to non-statutory 
subject matter. Claims 8-19 have been amended to obviate this rejection. 

The Examiner has rejected Claims 1-19 as being anticipated by Dunn. 
Applicants respectfully traverse this rejection. 

Referring to Dunn, there is disclosed a method and system for recovering a 
failed device on a master-slave bus. It is respectfully submitted just from the title of Dunn, it 
is distinct from applicants 1 claimed invention. Applicants' invention is not directed to 
recovering a failed device on a master-slave bus but with recovering a master unit itself when 
a slave unit fails. 

Dunn teaches that when a central master controller is used, it is advantageous to 
use a USB to connect peripherals to the central control. The USB has a number of limitations 
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that reduces utility. In actual use, bus implementations are susceptible to failures and may not 
be easy to pinpoint and may even be transient. Failures of a device and a USB can be caused 
by software or a particular state of the device in addition to poor power and regulations or a 
resource crunch. It is desirable to make recovery from errors increasingly transparent to the 
user. See column 2, lines 11-26. 

Dunn teaches a processing unit 21, a system memory 22, and a system bus 23 
that couples various system components including the system memory to the processing unit 
21. Dunn teaches a request to a device results in the building of an I/O request packet by the 
input output manager. The input output request packet is a data structure that is sequentially 
handled by the relevant drivers, each one of which performs its task while passing the input 
output request packet to the next driver. The system taught by Dunn allows detection of the 
failure of a hub and suspends processing of input output request packets requiring access to the 
failed hub and devices downstream of the failed hub. The hub-driver upstream of the failed 
hub that makes a function call on an application, name failure-recovery in this application. In 
addition to a USB interrupt transfer failing due to an actual physical USB hub device failure, it 
can fail from physical disconnection of a USB hub device from the USB. See column 8, lines 
12-27. If the reason for the USB hub device failure is determined to not have been caused by 
physical removal of the device, the USB hub recovery mechanism code is then activated. The 
first action that is taken by the USB hub recovery mechanism code is to set a flag in the 
software device extension for the failed USB hub device. This flag indicates to the software 
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functions that the USB hub has failed and is in the process of attempted recovery, and those of 
the software functions can deal with the situation accordingly. 

Software removal of all of the downstream child USB devices of the failed USB 
hub is performed. This essentially notifies the host operating system that the child USB 
devices are essentially no longer present, and software cleanup is performed to release all 
structures allocated on device initialization from memory. 

Once the failed USB hub device has been flagged in the software and software 
removal of the child devices has been updated, then the actual hub recovery mechanism 
code/failure-recovery code is scheduled to run. If the hub recovery mechanism itself fails, it 
is assumed that the condition that caused division of failure is still present, and the hub 
recovery mechanism is rescheduled. See column 8, line 24-column 9, line 8. 

When the scheduled hub recovery mechanism code is run, flags and conditions 
are checked to determine that the USB hub device is still present and not removed or powered 
down. Once these sanitary checks have been met, the port on the parent USB hub that the 
failed USB hub is connected to is reset. If this parent port reset fails, it is assumed that the 
USB hub is still experiencing the conditions that cause the original failure and the hub 
recovery mechanism is then rescheduled to run again. Once the parent port reset is successful 
the USB hub is then power down in order to reset the USB hub device itself. After the USB 



hub has been powered down, it is powered back up again. This should leave the USB hub on 
a fresh state. See column 9, lines 12-28. 

As is clear from the above description, the teachings of Dunn are focused totally 
on what happens when a USB hub connected to the processing unit 21 fails. It is not at all 
concerned, and is even silent as to what happens when the processing unit 21, in other words, 
the master unit, fails because a slave unit fails, as found in amended Claim 1. Because the 
focus on all the teachings of Dunn are directed to dealing with failures of the USB hubs, and 
not the failure of the master unit itself, Claim 1 is not anticipated by Dunn. In fact, Dunn 
really has nothing at all to do with applicants 1 claimed invention because Dunn is focused on a 
totally different problem. Accordingly, Claims 1-19 are patentable over Dunn. 

Applicants especially also bring to the Examiner's attention that many of the 
dependent claims that the Examiner submits is taught by Dunn, are not. For instance, Claim 
17 has the limitation of marking the variable slot as good if the switch did not abnormally 
terminate when the master unit accessed the first slave unit. Claim 17 is dependent to Claim 
14 which has the limitation of marking the variable slot as potentially bad if it is not marked 
potentially bad. The limitation of Claim 17 is not taught or suggested at all by the Examiner. 
The Examiner refers to figure 6 in Dunn for teaching this limitation. The specific teaching of 
step 605 in figure 6 is to set flag in the software device extension to indicate hub/device 
failure. It should be noted that this occurs after the step of the hub/device has failed, step 600. 
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If this procedure was followed as taught by figure 6, it would be in direct conflict with the 
teachings of Claim 17 of applicants because after the hub/device had failed before the flag was 
set, and the master unit failed because of this, when the master unit was turned back on, it 
would not know that the hub had failed because the act of indicating a hub failure is stated to 
occur after the failure of the device itself. This further underlines the different focus of Dunn 
in comparison to applicants' claimed invention. 

In view of the foregoing amendments and remarks, it is respectfully requested 
that the outstanding rejections and objections to this application be reconsidered and 
withdrawn, and Claims 1-8 and 10-19, now in this application be allowed. 



Respectfully submitted, 



KEVIN NOLISH, ET AL. 
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